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Abstract 


The  National  Defense  Authorization  Act  (NDAA)  of  2015,  cites  the  modular  open 
systems  approach  (MOSA)  as  both  a  business  and  technical  strategy  to  reduce  the  cost  of  system 
development  and  sustainment.  The  Better  Buying  Power  3.0  directive  sets  the  expectation  that 
MOSA  adoption  will  result  in  increased  innovation  and  competition,  leading  to  lower  cost.  With 
a  few  exceptions,  policy  directs  developers  to  consider  open  source  software  first  when  building 
new  capability.  Even  with  the  abundance  of  guidance,  a  lingering  question  remains.  What  is  the 
return  on  investment  (ROI)  for  building  and  or  migrating  systems  to  a  MOSA?  This  research 
sought  to  answer  that  question. 

To  answer  the  question  raised  above  a  review  of  a  cross-section  of  MOSA-related 
material  was  conducted.  The  material  included  industry  analysis,  system  and  software 
development  best  practices,  government/DoD  policy,  and  acquisition  law  and  guidance.  The 
research  revealed  an  overwhelming  amount  of  data  highlighting  the  benefits  of  using  MOSA 
both  in  industry  and  government.  Industry  has  fully  adopted  MOSA  and  continues  to  innovate  on 
ways  to  deliver  capabilities  and  software  services  using  MOSA  constructs.  One  can  see  MOSA 
in  service-oriented  architecture,  cloud  services,  modular  programing,  and  the  proliferation  of 
open-source  software. 

Numerous  examples  of  MOSA-related  efficiencies  were  uncovered.  These  include 
streamlined  development  made  possible  by  the  use  of  modular  and  open-source  software, 
reduced  reliance  on  proprietary  products  by  selecting  open  standards,  ease  of  sustainment  and 
upgrades  made  possible  by  modular  code,  well-defined  interfaces  using  commonly  agreed 
standards,  and  obeying  the  rules  of  cohesion  and  coupling.  A  number  of  specific  project 
examples  across  government  and  industry  attest  to  the  value  of  using  MOSA.  While  the  research 
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did  not  definitively  quantify  the  ROI  for  implementing  MOSA,  it  clearly  shows  there  is  a 
significant  ROI  for  adopting  MOSA. 


Chapter  1  -  Introduction 


Background 

Today’s  Army  systems  architecture  is  in  transition  from  stand-alone  components  to  a 
nearly  seamless,  systems-of-systems  architecture  where  connectivity  and  software  enhance  the 
capability  of  the  individual  pieces.  The  tank  becomes  more  effective  when  networked  and 
receiving  targeting  and  position  data  on  enemy  and  friendly  movements.  Aircraft  are  made  more 
effective  by  being  networked  and  receiving  battle  damage  assessments  and  command  and  control 
data.  Command  and  control  (C2)  systems  become  more  capable  when  they  are  networked  and 
can  share  data.  New  technologies  like  virtual  machines  and  networked  services  allow  us  to 
reduce  the  amount  of  hardware  and  software  we  field,  therefore  reducing  the  cost  of  software 
maintenance.  Additionally,  some  common  software  capabilities  that  reside  in  every  system  are 
no  longer  needed  in  every  system  and  are  therefore  duplicative.  With  the  emergence  of  software 
technologies  like  service-oriented  architectures  (SOAs)  and  cloud  services,  key  functionality  can 
be  codified  in  a  single  common  software  module.  The  module  should  be  available  to  all 
consumers  and  systems  that  can  access  the  service  over  the  network.  Combine  the  advances  cited 
above  with  the  emergence  of  systems  developed  using  the  modular  open  systems  approach 
(MOSA)  constructs,  including  open-source  software — “software  that  can  be  accessed,  used, 
modified,  and  shared  by  anyone”  (Scott  &  Rung,  2016,  p.  14) — and  a  whole  new  set  of 
possibilities  to  enhance  the  efficiency  and  capability  of  networks  (transport,  platforms,  and  C2 
systems)  become  achievable. 

Even  though  the  Army  network  is  in  transition,  its  current  state  is  still  characterized  by 
stand-alone  systems  with  single  core  functionality,  system-unique  data  structures,  and  software 
that  is  tightly  coupled,  which  makes  upgrades  difficult  and  expensive.  Tightly  coupled  software 
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has  high  interdependence  between  components.  A  change  in  one  component  could  necessitate 
multiple  other  changes.  This  is  not  because  of  negligence  on  anyone’s  part,  but  primarily  due  to 
the  evolution  of  systems  on  the  battlefield.  Many  of  the  current  systems  (Command  Post  of  the 
Future,  Distributed  Common  Ground  Station- Army,  Advanced  Field  Artillery  Tactical  Data 
System,  and  Tactical  Airspace  Integration  System)  were  developed  years  ago  with  minimal 
requirements  for  integrating  systems  and  sharing  data.  Because  it’s  difficult  to  get  competition 
for  needed  upgrades  on  the  current  architecture,  incumbent  prime  contractors  have  significant 
control  over  future  upgrades  and  software  maintenance.  Another  byproduct  of  the  current 
architecture  is  high  levels  of  duplication  across  systems.  For  example,  in  Army  command  post 
there  is  common  or  duplicative  functionality  in  many  systems.  A  few  good  examples  are 
multiple  message  readers,  multiple  applications  to  display  the  Common  Operational  Picture 
(COP)  and  multiple  instances  of  authentication  software.  With  a  MOSA  architecture  across  the 
command  post,  duplicate  software  and  the  cost  of  maintaining  that  software  could  be  reduced. 
Multiple  systems  in  the  command  post  could  use  a  single  COP  solution.  With  commonly  agreed 
upon  standards  and  open  solutions,  the  interoperability  challenge  should  decrease.  When  we 
begin  to  use  common  solutions  with  common  standards,  we  expect  cost  to  decrease  and  we  can 
eliminate  applications  whose  only  function  is  to  mediate  between  disparate  applications  with 
different  standards.  Finally,  stovepipe  systems  with  tightly  coupled  code  make  it  very  difficult  if 
not  impossible  to  attract  new  vendors  to  compete  for  contracts  to  update  systems.  Because  this 
software  is  likely  proprietary,  it  is  not  practical  from  both  a  legal  and  a  technical  perspective  for 
new  vendors  to  bid  on  upgrades.  This  situation  stifles  new  innovation  on  the  system  and  limits 
the  source  of  new  ideas  on  how  to  improve  the  system. 
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Before  we  go  further  we  need  to  provide  some  basic  definitions  to  set  the  proper  context 
and  provide  clarity  for  the  reader.  The  National  Defense  Authorization  Act  (NDAA)  for  2015 
defines  the  open  systems  approach  as  it  relates  to  information  technology  systems  as 

. .  .an  integrated  business  and  technology  strategy  that  (A)  employs  a  modular  design  and 
uses  widely  supported  and  consensus-based  standards  for  key  interfaces;  (B)  is  subjected 
to  successful  validation  and  verification  tests  to  ensure  key  interfaces  comply  with  widely 
supported  and  consensus-based  standards;  and  (C)  uses  a  system  architecture  that  allows 
components  to  be  added,  modified,  replaced,  removed,  or  supported  by  different  vendors 
throughout  the  lifecycle  of  the  system  to  afford  opportunities  for  enhanced  competition 
and  innovation...  (sections  3426-3427) 

One  of  the  upfront  challenges  of  doing  the  research  was  the  inconsistency  across  the 
Department  of  Defense  (DoD)  on  what  the  “A”  in  the  MOSA  acronym  stands  for.  In  some 
documents  it  represents  “architecture”  and  in  other  places  the  “a”  is  for  “approach”.  The  MOSA 
definition  is  fairly  consistent  with  one  exception.  The  Navy  explicitly  includes  open  source  in 
their  interpretation  and  they  call  out  software  reuse  as  a  MOSA  objective.  According  to  the  open 
systems  architecture  contract  guidebook  (DoD,  2013),  modular  dsign  is  “a  design  (organization) 
where  functionality  is  partitioned  into  discrete,  cohesive,  and  self-contained  units  with  well 
defined,  open  and  published  interfaces  that  permit  substitution  of  such  units  with  similar 
components  or  products  from  alternate  sources  with  minimum  impact  on  existing  units”  (p.  138). 

As  far  back  as  the  1970s,  colleges  and  universities  have  been  teaching  computer  scientists 
and  software  engineers  that  software  should  be  built  in  discrete  modules  that  are  cohesive  in 
functionality  within  modules  but  loosely  coupled  between  modules  to  ensure  that  changing  one 
module  does  not  drive  a  change  in  any  connected  module  (Yourdon  and  Constantine,  1979).  The 
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MOSA  approach  lowers  the  bar  for  vendors  seeking  to  compete  for  software  upgrade  contracts 
by  promoting  open  standards  and  removing  the  challenge  of  developing  code  that  must  interface 
with  propriety  standards  and  code.  According  to  the  NDAA  for  2015,  implementing  MOSA  will 
yield  significant  cost  savings  and  greater  interoperability.  The  NDAA  for  2015  directs  the 
Services  to  report  on  their  efforts  to  transition  major  defense  acquisition  programs  (MDAPs)  and 
major  automated  information  systems  (MAIS)  to  MOSA,  highlighting  any  issues  and  how  those 
issues  could  be  addressed.  According  to  Gavin  (2009),  having  the  right  strategy  for  how  we 
develop  systems  and  software  is  becoming  more  important  for  multiple  reasons.  They  include  the 
high  cost  of  software  development  and  sustainment,  the  steep  rise  in  the  amount  of  software  in 
defense  systems,  and  our  critical  dependency  on  software  for  all  aspects  of  society. 

Software  in  DoD  systems  has  increased  by  more  than  an  order  of  magnitude  every  decade 
(Scherlis,  2012).  The  amount  of  software  in  weapon  systems  is  increasing  at  a  staggering  rate. 
According  to  Lockheed  Martin  (2015),  each  F-35  Raptor  will  have  close  to  eight  million  lines  of 
code,  more  than  any  aircraft  built  previously.  There  are  major  challenges  in  software 
development  today.  One  is  the  cost  of  software  and  its  sustainment  over  the  systems  life  cycle. 

By  most  estimates,  the  largest  slice  of  a  systems  life-cycle  cost  is  operations  and  sustainment 
cost  (Haines,  2001).  Another  related  challenge  is  the  work  and  cost  associated  with  making 
required  software  updates  and  the  associated  integration.  This  challenge  is  exacerbated  by  the 
high  rate  of  hacking  incidents  and  the  rapid  introduction  of  malicious  code,  which  threaten  the 
security  and  performance  of  systems  and  networks.  Recent  red  team  assessment  of  operational 
exercises  (network  integration  events)  reveals  significant  vulnerabilities  in  our  systems  and 
software.  Cyberattacks  are  becoming  more  numerus  and  more  effective  according  the  Bennett 
(2016).  To  survive  in  the  current  cyber  environment,  developers  must  be  able  to  incorporate 
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upgrades  rapidly.  Government  systems  across  many  departments,  including  defense,  energy,  the 
Environmental  Protection  Agency,  and  homeland  security  must  enable  rapid  integration  of 
updates.  Systems  that  can  be  easily  updated  based  on  changing  requirements  and  threats  to  those 
systems  are  needed  to  maintain  performance  and  system  security. 

The  DoD  has  been  pushing  the  importance  of  MOSA  in  law,  policy,  and  acquisition 
contract  guidance  since  at  least  2004.  DoD  industry  partners  generally  agree  with  the  strategy 
and  are  applying  MOSA  to  many  programs,  both  defense  related  and  commercial.  Our 
lawmakers  have  integrated  MOSA  mandates  in  law.  However,  we  are  still  moving  slowly  in 
transitioning  to  MOSA  for  current  and  future  systems,  and  we  don’t  have  adequate  data  that 
quantifies  the  cost  savings  to  be  achieved. 

Problem  Statement 

The  expected  benefits  of  transitioning  to  a  MOSA  for  acquisition  programs  include 
reduced  cost,  increased  competition  and  innovation,  and  ease  of  integration  and  sustainment.  A 
big  challenge  will  be  to  transition  existing  systems  to  MOSA;  this  will  be  costly  and  will  occur 
over  many  years.  It  will  require  changes  in  existing  contracts  and  a  shift  in  how  we  approach 
intellectual  property.  However,  little  data  exist  that  quantifies  the  possible  return  on  investment 
(ROI)  for  transitioning  programs  to  MOSA.  Significant  concerns  about  the  status  of  MOSA 
implementation  were  raised  by  survey  results  collected  by  the  Army-led,  joint  Better  Buying 
Power  3,  MOSA  study  team,  which  primarily  consisted  of  general  officers  and  Senior  Executive 
Service-level  acquisition  leaders.  Key  concerns  included  the  following  according  to  S.  Blanchett 
(personal  communication,  March  15,  2016): 

1.  The  PM’s  staff  lack  the  experience  required  to  implement  MOSA. 

2.  Clear  guidance  on  MOSA  compliance  is  lacking  on  all  levels^ 
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3.  Incumbent  contractors  have  little  incentive  to  cooperate  with  MOSA  goals. 

4.  Associated  intellectual  property  guidance  lacks  clarity  and  consistency. 

While  it  may  appear  intuitive  that  migrating  to  MOSA  will  reduce  the  cost  of  developing 
and  sustaining  systems,  there  is  little  quantitative  data  on  the  expected  savings.  This  research 
attempted  to  identify  and  quantify  the  ROI  for  transitioning  programs  to  MOSA. 

Purpose  of  This  Study 

The  results  of  this  study  should  inform  acquisition  leaders  and  practitioners  about  the 
ROI  for  migrating  to  MOSA.  In  order  to  weigh  the  promise  of  MOSA  and  the  current  state  of 
MOSA  migration,  this  study  assessed  a  significant  body  of  data  on  modular  design  and  open 
systems  approaches  and  sought  supporting  and  contradictory  information  on  the  value  of  MOSA. 

.  It  focused  on  current  technologies  and  practices  in  the  area  of  MOSAand  highlights  successes 
in  MOSA  compliance  and  issues  affecting  adoption  and  migration  to  MOSA.  Concrete  examples 
are  given  of  where  a  positive  ROI  has  been  realized  from  taking  on  MOSA.  The  study  sought  to 
explore  the  following  questions. 

1.  What  is  the  expected  ROI  for  MOSA  migration? 

2.  Will  Army  systems  under  a  MOSA  construct  ease  the  challenge  of  upgrading  and 
integrating  systems  and  platforms? 

3.  Should  MOSA  be  applied  to  systems/platforms  in  sustainment? 

Significance  of  This  Research 

This  research  is  significant  because  of  its  potential  to  shed  light  on  how  we  can  improve 
acquire,  sustain,  and  update  our  military  systems.  The  research  results  help  to  validate  the  value 
proposition  for  MOSA,  which  consists  of  increased  competition,  simplified  upgrades  through 
modular  design,  common  open  standards,  delayed  obsolescence,  and  reduced  sustainment  cost 
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through  open  approaches  and  increased  innovation.  The  DoD  must  improve  its  ability  to  develop 
and  maintain  systems  and  related  software.  It  is  critical  to  our  ability  to  deliver  capability  to 
warfighters.  Many  challenges  are  associated  with  improving  system  performance  and  security 
while  reducing  delivery  time  and  cost.  We  must  address  all  the  challenges  in  a  time  of  shrinking 
defense  spending  coupled  with  the  emergence  of  adversaries’  peer  or  near-peer  technology  and 
systems.  Numerous  government  and  industry  leaders  believe  using  open  systems  approaches 
coupled  with  adopting  modular  designs  will  address  many  of  the  problems  identified  above.  Both 
Secretary  of  Defense  Carter  and  the  defense  acquisition  executive,  Mr.  Kendall,  urged  the 
adoption  of  MOSA  across  DoD.  The  Defense  Department’s  Better  Buying  Power  initiatives 
continuously  urge  the  use  of  modular  design  and  open  systems  approaches  to  address  the  stated 
objectives  and  shortcomings.  According  to  Fitzgerald,  Levine  and  Parziale  (2016),  America’s 
ability  to  regain/maintain  our  technological  edge  over  our  adversaries  is  linked  to  whether  we 
embrace  and  prioritize  open  systems.  This  study  addresses  some  of  the  foregoing  concerns  and 
sheds  new  light  on  the  topic. 

Overview  of  the  Research  Methodology 

The  hypothesis  for  this  paper  is  that  applying  MOSA  to  Army  systems  will  reduce  the 
cost  of  system  development  and  sustainment.  We  know  there  will  be  some  upfront  cost 
associated  with  developing  new  systems  and/or  transitioning  existing  systems  to  MOSA,  yet  the 
expectation  is  that  there  will  be  a  positive  ROI.  A  mixed  methodology  was  used  for  researching 
this  topic,  including  evidence-based  research  and  case  study  research,  both  supported  by  a 
literature  review.  This  evidence  derives  from  an  examination  of  MOSA-related  data,  studies, 
journals,  papers,  successful  and  unsuccessful  initiatives,  and  associated  technology.  The  research 
also  includes  previously  conducted  surveys  on  the  topic  of  MOSA. 
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Limitations 


Determining  the  ROI  for  adoption  of  MOSA  would  require  a  clear  determination  of  the 
cost  to  adopt  MOSA.  A  commonly  accepted  cost  for  adopting  MOSA  in  DoD  does  not  exist. 
Therefore,  for  the  purpose  of  this  research,  ROI  equals  cost  savings  plus  cost  avoidance  in 
development  and  sustainment  attributed  to  the  adoption  of  MOSA.  The  initial  review  of  literature 
and  evidence  on  MOSA  found  little  quantitative  data  on  the  cost  savings  associated  with  modular 
design  and  open  systems  approaches.  Many  of  the  sources  reviewed  include  statements  about  the 
value  proposition  for  open  systems  approaches.  Part  of  the  value  proposition  is  that  open 
software  can  be  obtained  at  reduced  cost.  There  is  also  evidence  that  increased  participation  in 
open  forums  will  yield  software  code  and  technologies  that  were  not  developed  at  government 
expense  but  provide  great  value  because  participation  allows  participants  to  shape  solutions  to 
meet  their  needs. 

The  second  limitation  is  that  surveys  and  interviews  were  not  developed  or  conducted  as 
part  of  this  research.  This  limited  the  ability  to  include  specific  cost  data  from  the  MOSA  efforts 
of  program  managers  and  industry  developers. 


Chapter  2  -  Literature  Review 


The  literature  review  focused  on  four  areas:.  (1)  MOSA-related  technologies  and  related 
processes;  (2)  past,  ongoing,  and  planned  MOSA  efforts  across  the  government  and  industry;  (3) 
studies,  papers,  journals,  policy,  and  guidance  on  MOSA;  and  (4)  documents  with  quantitative 
data  that  contain  specific  accounts  of  savings  reaped  from  MOSA  implementation.  Multiple 
sources  and  source  types  were  used  for  each  category,  including  legal  documents;  government 
reports,  studies,  and  survey  results;  books;  and  online  material  (blogs,  journals,  and  other  web 
content). 

MOSA  technologies  and  related  processes.  In  the  area  of  technology,  several  key 
products  are  included.  Fogel  (2009)  provided  a  brief  but  thorough  history  on  open  source 
software  (OSS)  efforts,  including  both  successes  and  failures.  He  discussed  the  key  players  and 
motivations  in  open  source  projects,  ranging  from  the  project  originator  who  has  a  need  or 
interest  in  a  certain  product,  to  the  partners  who  have  a  shared  interest  in  the  product  and  are 
willing  to  help  develop  the  code.  According  to  Fogel,  an  early  example  of  an  open  source  project 
(and  one  of  the  best)  was  the  collaboration  to  develop  the  hardware  independent,  UNIX 
operating  system.  The  academic  community  joined  forces  from  geographically  dispersed 
locations  to  lead  that  development.  Perhaps  the  most  popular  and  far-reaching  example  of  an 
open  source  project  is  the  Intemet/World  Wide  Web.  Fogel  also  gave  a  step-by-step  guide  on 
how  to  initiate  and  manage  a  free  software  project,  addressing  key  details  from  the  technical 
infrastructure,  to  requirements,  to  open  source  licensing  options.  In  chapter  one  the  author 
tackled  and  clarified  the  word  “free”  in  the  context  of  free  software.  According  to  Fogel,  “free” 
in  the  context  of  free  software  refers  to  the  freedom  to  do  what  you  want  with  the  code,  including 
sharing,  changing,  and  adding  features.  The  example  Fogel  used  in  the  book  is  the  battle  between 
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Microsoft  and  Netscape  in  the  1990s  to  capture  the  browser  market.  Both  companies  gave  away 
their  browsers  free  of  charge,  but  users  were  not  free  to  make  changes  to  the  code.  Hence,  free  in 
this  example  did  not  mean  free  to  share,  upgrade,  or  change  the  code  in  any  way.  In  essence  the 
products  were  free  of  charge  yet  proprietary.  From  a  government  perspective,  under  the  MOSA 
construct  we  want  products  that  are  free  from  both  perspectives,  free  of  charge  and  free  to 
manipulate.  One  of  several  important  aspects  of  Fogel’s  book  is  his  introduction  and  analysis  of 
intellectual  property  and  its  relationship  to  competition. 

Another  source  used  was  a  technical  paper  from  the  Center  for  a  New  American  Society. 
The  authors  (Fitzgerald  et  al.,  2016)  make  a  compelling  case  that  beyond  reduced  cost, 
interoperability,  and  innovation  there  are  additional  and  equally  important  benefits  of  a  MOSA. 
They  see  MOSA  as  an  essential  component  of  the  acquisition  ecosystem  the  country  must  have 
to  produce  the  kind  of  software  and  system  capabilities  needed  to  keep  pace  with  our  adversaries. 
Fitzgerald  et  al.  (2016)  highlight  the  gap  between  industry’s  heavy  reliance  on  MOSA  as  a 
catalyst  for  rapid  development  of  cutting-edge  software  and  the  DoD,  which  they  say  does  not 
prioritize  software  development  at  a  high  enough  level.  They  see  MOSA  as  a  critical  component 
of  our  ability  to  win  the  technology  race.  Fitzgerald  et  al.  say  that  implementing  MOSA  creates  a 
software  platform  that  will  accelerate  innovation  of  software/system  capabilities.  In  summary, 
the  research  revealed  that  open  systems  is  more  about  adopting  a  new  technical  methodology  for 
acquiring  capability  that  reduces  cost,  eases  the  interoperability  challenge,  and  enables  greater 
innovation  and  competition. 

Past,  ongoing  and  planned  MOSA  efforts  across  the  government  and  industry.  To 

identify  and  create  a  baseline  for  the  status  of  MOSA,  a  number  of  MOSA  initiatives  were 
investigated,  including  but  not  limited  to  the  following  products.  As  mentioned  in  the  previous 


10 


section,  one  of  the  most  notable  past  examples  of  an  open  source  initiative  was  the  development 
of  protocols  and  standards  that  power  the  Internet:  Open  Systems  Interconnect  (OSI)  and 
Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP).  According  to  Kelty  (2009),  “the 
success  of  TCP/IP  protocols  forced  multiple  competing  networking  schemes  into  a  single 
standard — and  a  singular  entity,  the  internet...”  (pp.  38-39).  The  early  efforts  like  TCP/IP  and 
OSI  helped  shape  the  concepts  and  identify  the  goodness  of  free  software  and  open  source.  The 
Navy,  Army,  and  industry  initiative — Future  Airborne  Capability  Environment  (FACE) — is  an 
industry-government  consortium  that  is  developing  an  open  computing  environment  and  open 
software  standard  for  fixed  and  rotary  wing  aircraft.  FACE  is  a  trademark  of  The  Open  Group, 
which  is  a  global  consortium  that  enables  the  achievement  of  business  objectives  through  IT 
standards  (Stevens,  Howington,  Boyett,  &  Avery,  2016).  If  properly  implemented,  FACE 
promises  to  deliver  modular  open  components  that  can  be  ported  from  one  platform  to  another 
with  minimal  integration  challenges. 

The  Army’s  Common  Operating  Environment  (COE)  is  yet  another  effort  that  embraces 
MOSA.  The  Army  COE  includes  FACE  and  Vehicle  Integration  for  C4ISR/EW  Interoperability 
(VICTORY)  as  part  of  an  overarching  initiative  to  speed  the  delivery  of  capability  to  the  soldier. 
These  initiatives  also  reduce  system  development  cost  and  time  required  to  react  to  changing 
warfighter  needs.  The  COE  effort  began  with  an  Execution  Order  from  the  Army  Chief  of  Staff 
directing  COE  implementation.  The  order  was  subsequently  followed  by  an  enterprise 
architecture  developed  by  the  Army  chief  information  officer  and  an  Information  Systems 
Capability  Development  Document  developed  by  Headquarters  TRADOC.  A  core  component  of 
the  COE  strategy  is  to  transition  legacy  systems  to  a  MOSA.  The  strategy  also  encourages 
operational  functionality  to  be  encapsulated  in  widgets  and/or  applications  integrated  on  a 
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common  software  platform.  This  approach  emulates  industry  MOSA  constructs  such  as  the 
Google  Android  software  platforms,  which  form  part  of  the  ecosystem  for  the  millions  of 
functional  apps  and  widgets  available  for  use  by  smartphones  and  tablets.  Figure  1  is  the  COE 
Technical  Reference  Model,  showing  the  layers  of  a  modular  architecture  from  transport,  to 
common  services  used  by  all,  to  user-facing  functional  widgets  and  apps  used  by  the  soldier. 
These  apps  and  widgets  aid  the  soldier  in  numerous  ways,  including  route  planning,  viewing  the 
common  operational  picture,  and  C2  functions.  It’s  important  to  highlight  here  that  once  the 
industry  platforms  were  developed,  unprecedented  innovation  on  the  apps  and  widgets  occurred, 
generating  millions  of  modular  applications  and  widgets  representing  a  wide  range  of 
functionality.  It’s  safe  to  say  that  no  one  could  have  imagined  the  amount  and  types  of  widgets 
that  were  developed  for  Android  and  Apple. 


Figure  1  -  The  Army  Common  Operating  Environment  Technical  Reference  Model 
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The  Army  VICTORY  initiative  is  an  open  specification  focused  primarily  on  sharing 
information  between  components  on  ground  platforms.  The  VICTORY  architecture  is  based  on 
common  interface  standards  implemented  across  a  common  vehicle  bus.  Once  these  standards 
are  implemented,  platform  owners  will  have  a  plug-and-play-like  experience  when  integrating  IT 
and  communications  electronic  components  on  the  platform.  VICTORY  will  also  take  into 
account  the  size,  weight,  and  power  constraints  of  the  platform.  In  summary,  research  revealed 
multiple  examples  of  successful  modular  open  architecture  efforts  and  some  failures.  Many 
industry  open-source  products  are  thriving.  The  FACE  initiative  appears  to  be  on  the  edge  of 
delivering  on  the  promise  of  an  operating  environment  for  aircraft  that  can  produce  reusable 
open  code  for  use  in  multiple  platforms. 

There  are  numerous  open-source  initiatives  in  industry.  One  popular  initiative  is  web 
servers.  These  open  source  products  dominate  the  web  server  landscape,  and  they  make  up  the 
software  responsible  for  the  distribution  of  content  on  the  World  Wide  Web.  According  to 
Muilwijk  (2016),  Apache  and  NGINX  web  servers  together  power  over  80  percent  of  all  web 
sites.  The  significance  here  is  huge,  project  managers  with  a  requirement  to  serve  content  over 
the  web  can  forgo  the  challenge  and  the  expense  of  developing  a  web  server.  The  program 
manager  who  needs  a  web  server  can  choose  to  use  one  of  the  open  source  products. 

Studies,  papers,  journals,  policy,  and  guidance  on  MOSA.  In  this  area  there  are  many 
documents:  The  NDAA  of  2015,  section  801;  the  Better  Buying  Power  3.0  directive  from  the 
Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics  (USD[AT&L]);  and  the 
open  systems  architecture  contract  guidebook  all  provide  direction  to  the  Services  on  moving 
forward  with  MOSA.  According  to  the  NDAA  of  2015,  the  Services  should  be  pursuing  MOSA 
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for  MDAPs  and  MAIS  to  reduce  cost.  In  Better  Buying  Power  2.0,  systems  developers  were 
instructed  to  use  open  systems  for  the  acquisition  of  new  systems.  The  Better  Buying  Power  3.0 
directive  instructs  the  acquisition  community  to  use  MOSA  to  stimulate  innovation  (Kendal, 
2015).  According  to  policy  issued  by  the  Director  for  Defense  Systems  (Lamartin,  2004), 
acquisition  programs  are  to  address  MOSA  early  in  their  program  acquisition  planning  as  a 
means  to  develop  the  future  capability  needed  for  our  soldiers,  sailors,  and  airman.  There  is  no 
shortage  of  guidance  and  directives  urging  the  use  of  MOSA. 

Documents  containing  dollar  amounts  or  examples  of  specific  quantities  of  funds 
saved  by  implementing  MOSA.  Information  in  this  category  is  sparse.  A  report,  endorsed  by 
the  Committee  on  Aging  Avionics  in  Military  Aircraft,  captured  the  results  of  a  detailed  analysis 
on  how  the  Services  might  address  the  problem  of  aging  avionics  in  aircraft  (Air  Force  Science 
and  Technology  Board,  2001).  According  to  the  report  the  cost  associated  with  replacing 
avionics  components  once  they  became  obsolete  was  very  high.  One  of  the  recommendations  in 
the  report  was  to  adopt  MOSA  in  the  development  and  maintenance  of  aircraft,  specifically  the 
avionics.  The  report  includes  a  finding  that  the  widespread  application  of  MOSA  would  make 
the  management  of  the  ageing  avionics  problem  more  affordable. 

The  Navy  distinguishes  itself  by  embracing  OSS  under  their  open  architecture  construct. 
Gavin  (2009)  provides  a  long  history  of  the  Navy’s  engagement  with  open  architecture.  His 
presentation  highlights  the  Navy’s  open  architecture  construct  and  core  principles,  which  include 
moduler  design  and  life-cycle  affordability.  According  to  Gavin,  an  open  source  strategy  is 
essential  for  the  21st  century  and  is  a  means  to  achieve  more  reliable  systems  and  to  increase 
innovation.  The  Navy  specifically  identifies  greater  software  reuse  as  an  objective.  The  other 
Services  and  organizations  seem  to  limit  their  definition  of  open  approaches  to  open 
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architectures  and  open  standards.  Gavin’s  presentation  traces  the  history  of  open  architecture 
from  2004  to  2009.  Key  milestones  along  the  timeline  include  the  issuance  of  operational 
architecture  and  requirements  policy.  According  to  Gavin,  significant  accomplishments  tied  to 
open  architecture  implemention  include  component  reuse  across  the  Marine  Air  Ground  Task 
Force  (MAGTAF);  reduced  cost,  per  boat,  per  year  of  $2.9  million  for  the  submarine  warfare 
tactical  system;  and  reduction  of  shipboard  networks  to  one,  after  implementation  by 
Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES),  resulting  in  a  $4  million 
saving  per  ship.  Table  1  shows  the  accomplishments  across  multiple  Navy  programs. 


Table  1  -  Progress  Across  the  Navy  Enterprise 


Open  Source  Approach  Across  the  Navy  Enterprise 

Navy-Marine 

Element/System 

Action 

ROI 

Impact 

MAGTAF  C2 

Reusing  components 
across  systems  reduces 

cost 

Reduced  cost 

Mobile  User  Objective 
System 

Use  of  commercial 

standards  for  waveform 

85%  reused  or  modified 

software 

P-8  A 

MOSA  as  technical 

criteria 

68%  reuse  of  mission 

software 

Littoral  Combat  Ship 
Mission  Modules 

Uses  well-defined 

interfaces  and 

commercial  standards 

Submarine  Warfare 

Federated  Tactical 

System 

Reduced  cost  per  boat 
by  $2.9  million  per  year 

Common  Processing 

Unit 

Use  of  commercial 

FI  a  rdwa  re/Software 

CANES 

Reduced  4  shipboard 
networks  to  1 

Saved  $4  million  per 
ship  (estimated) 
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Chapter  3  -  Research  Methodology 

Research  Hypothesis 

For  this  research  project,  the  hypothesis  is  that  applying  MOSA  to  Army  systems  will 
reduce  the  cost  of  system  development  and  sustainment. 

The  alternative  hypothesis  is  that  applying  MOSA  to  Army  systems  will  ease  integration 
and  upgrade  challenges.  There  is  general  acceptance  that  MOSA  will  reduce  the  cost  of  system 
development  and  sustainment.  There  are  several  reasons  for  this  effect.  Over  time,  buyers  have 
learned  that  prices  are  lower  when  there  is  competition  in  the  marketplace.  This  rule  applies  to 
the  acquisition  of  systems  and  software.  The  use  of  OSS  and  especially  open  standards  allows 
the  government  to  reap  the  benefits  at  the  expense  of  others.  The  cost  of  developing  the  open 
products  were  borne  by  others  who  developed  the  products.  Using  modular  design  and  open 
standards  should  drive  down  the  cost  of  maintenance  and  updates  and  any  attendant  integration 
cost. 

Given  the  known  cost  drivers  identified  above  the  research  sought  to  uncover  data  and 
quantifiable  information  at  a  lower  level  of  granularity  than  what  is  already  available. 

Research  Design 

In  order  to  address  the  hypothesis  and  related  questions,  the  research  followed  the 
following  methods. 

1.  Case  Study  Research.  As  a  means  to  investigate  the  hypothesis,  research  assessed 
many  software  development  programs  and  initiatives.  First  the  research  sought  to  determine 
whether  some  aspect  of  MOSA  is  being  used  by  the  program  or  initiative.  The  three  key  MOSA 
aspects  are  modular  design,  agreed  standards,  and  the  use  of  open  source  products.  If  any  one  of 
the  three  aspect  exists,  the  case  was  assessed. 
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2.  Causal  Correlation  Research.  The  research  sought  to  discover  the  relationship  between 
MOSA  and  cost.  For  example,  if  there  is  a  relationship  between  competition  and  cost,  the 
research  would  expose  that  relationship  and  uncover  instances  where  there  has  been  an  impact 
and  the  level  of  the  impact.  The  aim  is  to  identify  specific  examples  in  the  literature  that 
highlight  concrete  cost  savings  realized  after  transitioning  to  MOSA. 

3.  Evidence-based  Research.  Evidence-based  research  was  used  widely  throughout  the 
project  to  identify  and  analyze  any  evidence  pertinent  to  proving  or  disproving  the  hypothesis. 
Bias  and  Error 

Close  attention  was  paid  to  ensure  that  bias  was  not  introduced  in  the  research.  Because 
so  much  attention  is  being  paid  to  MOSA  implementation  at  the  highest  levels  within  the  DoD, 
some  may  be  tempted  to  overstate  the  success  of  their  program  with  regard  to  supporting  or 
disproving  the  value  of  MOSA.  Additionally,  a  significant  amount  of  data  on  MOSA  represent 
the  views  of  industry,  academics,  and  practitioners.  All  data  was  evaluated  to  eliminate 
inaccuracies  from  any  source.  Where  feasible,  peer  reviews  were  used  to  further  attempt  to 
reduce  bias  and  errors. 

To  ensure  the  validity  of  data  and  associated  findings  and  recommendations,  information 
was  cross-referenced  by  using  multiple  sources  when  possible.  Inquiries  were  made  to  verify 
information.  According  to  Calabrese  (2006)  “validity  refers  to  the  accuracy  or  usefulness  of  a 
measurement”  (p.  58).  Another  approach  used  to  bolster  research  validity  was  to  include  in  the 
review  any  data  supporting  or  countering  the  research  hypothesis.  Finally,  peer  reviews  of  the 
paper  served  as  an  additional  means  to  ensure  accuracy  and  validity  of  data. 
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Chapter  4  -  Findings 


The  focus  for  this  research  was  to  identify  the  ROI  for  building  new  systems  and 
migrating  existing  programs  to  MOSA.  The  research  uncovered  lots  of  data  on  MOSA,  its 
definition,  components,  expected  benefits,  and  insights  into  the  level  of  adoption  across  industry 
and  the  DoD.  One  finding  that  should  be  mentioned  up  front  is  that  while  OSS  was  not  widely 
mentioned  in  most  of  the  data  reviewed  (with  the  exception  of  Navy  documentation),  OSS 
should  be  included  or  at  least  considered  in  any  discussion  of  MOSA.  In  accordance  with  the 
DoD’s  open  systems  architecture  contract  guidebook,  “OS A  principles  are  also  supportive  of  and 
consistent  with  using  Open  Source  Software  (OSS)  in  systems.... use  of  OSS  does  not,  by  itself, 
constitute  compliance  with  OSA”  (DoD,  2013,  p.  xi).  From  this  point  forward  in  the  research, 
OSS  will  be  addressed  as  an  essential  component  of  MOSA.  In  addition  to  the  primary  question 
related  to  the  ROI  from  MOSA,  the  analysis  addresses  the  following  related  questions: 

1.  What  is  the  expected  ROI  for  MOSA  migration? 

2.  Will  Army  systems  under  a  MOSA  construct  ease  the  challenge  of  upgrading  and 
integrating  systems  and  platforms? 

3.  Should  MOSA  be  applied  to  systems/platforms  in  sustainment? 

The  Effect  We  Want  from  a  MOSA  on  Our  Systems 

From  a  high-level  perspective,  MOSA  has  two  main  components:  a  modular  architecture 
and  an  open  systems  approach.  Taken  separately,  each  one  can  have  a  significant  impact  on 
reducing  the  development  and  sustainment  cost  of  systems;  when  implemented  together  they  can 
become  a  game  changer  in  terms  of  ROI,  as  well  as  for  speed  of  product  delivery,  ease  of 
integration,  and  increased  innovation.  According  to  the  Air  Force  Science  and  Technology  Board 
(2001,  p  32)  a  modular  system  has  the  following  attributes: 
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•  The  system  is  designed  to  maintain  external  hardware/software  interface  capability  of 
a  module  independent  of  changes  made  internal  to  module 

•  Both  hardware  and  software  (physical  and  functional/logical)  aspects  of  architectural 
interfaces  are  included  in  the  system. 

•  The  systems  can  be  scaled  in  capability  by  incrementally  adding  or  deleting  modules 
of  functionality 

•  The  systems  can  be  maintained  or  upgraded  by  selective  replacement  of  elements 
without  impacting  the  other  elements 

•  The  systems  can  reuse  existing  elements  and  provide  reusable  elements  to  the  other 
systems 

By  contrast  open  systems  have  the  following  attributes: 

•  All  the  attributes  of  a  modular  system  are  also  included  in  an  open  system 

•  The  system  can  be  integrated  from  elements  supplied  from  multiple  sources 

•  Choice/application  of  standards  represent  a  design  decision  that  follows  open  system 
partitioning  and  functional  interface  definition 

These  attributes  taken  together  provide  a  description  of  how  we  want  future  system  to  be 
developed. 

Analysis 

Research  results  show  a  high  probability  for  realizing  a  positive  ROI  for  implementing 
MOSA.  After  reviewing  data  and  analysis  from  both  industry  and  the  DoD,  the  findings  reveal 
there  is  and  would  be  a  high  return  on  investment  across  both  DoD  and  commercial  industry. 

Both  industry  and  the  DoD  have  experienced  benefits  from  MOSA,  but  the  industry  experience 
has  differed  from  the  DoD  experience.  Industry  moved  relatively  quickly  on  many  aspects  of 
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MOSA  and  continues  to  innovate  on  the  MOSA  technologies.  Industry  has  pushed  forward  with 
OSS,  service  oriented  architectures,  and  cloud  services  to  name  a  few.  In  some  cases  the  DoD 
has  adopted  some  of  these  technologies  and  in  some  cases  it  is  playing  catch-up  from  a  distance. 
The  DoD  is  using  MOSA,  specifically  a  service  oriented  architecture,  to  incrementally  replace 
legacy  C2  systems  (Kendall,  2017). 

Industry  adopts  MOSA.  Industry  has  clearly  adopted  and  embraced  MOSA  in  a 
significant  way,  and  they  have  seen  the  biggest  ROI  from  MOSA.  We  simply  have  to  look  at  the 
Android  market  to  see  how  the  application  of  MOSA  (e.g.,  open  standards,  modular  architecture, 
OSS)  has  led  Android  to  be  the  leader  in  the  mobile  device  market.  Android  is  built  on  the  Linux 
operating  system,  which  is  OSS.  Apple  and  its  modular  IOS  platform  has  also  had  tremendous 
success  with  MOSA,  even  though  it’s  not  fully  MOSA  because  of  its  proprietary  platform. 
According  to  The  Statistics  Portal  (2017),  Android  users  had  2,800,000  apps  and  Apple  users 
had  200,000  apps  to  select  from.  The  diversity  of  app  providers  and  the  total  number  of  apps 
indicate  a  high  level  of  competition  and  innovation  in  the  space.  Competition  and  innovation  are 
two  key  DoD  objectives  for  using  MOSA,  according  to  the  USD(AT&L)’s  Better  Buying  Power 
initiatives. 

According  to  Gavin  (2009),  the  use  of  OSS  in  the  private  sector  is  on  the  rise.  Both  DoD 
and  the  private  sector  use  OSS  in  critical  applications.  Two  examples  often  mentioned  include 
Android  and  Apache  open  software  products.  The  Army  chose  the  Android  operating  system  for 
its  Net  warrior  system  partly  because  it  is  derived  from  Linux,  open  software.  There  is  no  up¬ 
front  charge  for  using  Android;  however,  some  device  manufacturers  must  pay  fees  to  get  a 
license  to  use  some  of  the  related  software  applications.  The  Apache  web  server  may  be  the 
world’s  most  used  web  server,  and  it  is  also  used  widely  across  the  DoD.  Both  industry  and  the 
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DoD  rely  heavily  on  web  apps  and  services.  Apache  is  OSS,  and  it  is  free  when  acquired  from 
the  Apache  Software  Foundation.  According  to  Fitzgerald  et  al.  (2016)  the  Apache  Foundation 
has  software  on  almost  half  the  web  servers  worldwide.  Apache  has  a  liberal  use  license  that 
allows  users  to  modify/extend  the  software  as  required. 

The  value  of  OSS.  To  quantify  the  ROI  for  migrating  systems  and  programs  to  a  MOSA 
construct,  first  you  must  have  a  way  to  determine  the  value  of  OSS.  Second,  you  must  determine 
what  it  would  cost  your  program  if  you  did  not  have  access  to  OSS  and  had  to  develop  the  code 
on  your  own.  For  example,  the  popular  Linux-based  operating  system  Fedora,  which  is  OSS, 
would  cost  an  estimated  $11.5  billion  to  build  according  to  Vaughan-Nichols  (2009).  The 
estimate  is  based  on  analysis  done  by  Black  Duck  Software,  an  open  source  legal  management 
firm  using  the  popular  cost-estimating  tool  Constructive  Cost  Model.  The  firm  estimates  “there  is 
[sic]  over  200,000  open  source  projects  representing  4.9  billion  lines  of  code,”  and  that  it  would 
cost  $387  billion  to  reproduce  (Vaughan-Nichols,  p.  5) 

The  challenge  of  developing  software  intensive  systems  in  the  OSS  era  is  getting  simpler. 
Instead  of  developing  and  integrating  disparate  and  often  proprietary  components  as  in  the  past, 
there  is  a  new  model.  In  the  new  model  the  lead  engineer  can  just  select  from  a  list  of  OSS 
products  and  integrate  them.  He  can  select  an  operating  system,  a  database  management  system, 
a  web  server,  and  an  application  server,  all  well  documented,  open  source,  and  many  free  of 
charge. 

Is  open  source  software  secure?  Numerous  questions  have  been  raised  concerning  the 
security  of  OSS,  but  many  of  the  myths  about  the  OSS  used  in  a  national  security  context  have 
been  debunked.  According  to  Fitzgerald  et  al.  (2016),  using  open  source  code  does  not  mean  you 
must  share  the  changes  you  make  to  the  code  publicly  and,  because  OSS  code  is  viewable,  does 
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not  mean  the  code,  once  deployed,  can  be  modified  by  a  third  party.  According  to  Winnergren 
(2009),  OSS  is  consistent  with  commercial  software  and  should  be  given  preference  over  custom 
software  when  it  is  found  to  satisfy  requirements.  A  custom  software  solution  should  be  used 
only  when  an  OSS  solution  can’t  be  found.  Custom  software  should  be  developed  and  published 
as  OSS  so  it  can  be  used  by  others  with  a  common  need  (Scott  &  Rung,  2016).  Finally,  the  level 
of  scrutiny  that  happens  under  open  development  works  to  minimize  the  possibility  of  a  hidden 
bug  getting  into  the  code. 

Industry  has  embraced  MOS A/OSS.  Without  a  doubt  these  technologies  definitely  offer  a 
positive  ROI  from  multiple  perspectives.  The  technologies  have  reshaped  how  industry  delivers 
IT  services  to  the  market.  Industry  quickly  realized  the  efficiencies  and  cost  savings  to  be  had  by 
using  MOSA.  They  offer  agility  in  how  they  deliver  capability,  they  foster  innovation  and 
competition,  and  they  reduce  the  burden  of  software  sustainment.  According  to  Fitzgerald  et  al. 
(2016),  “without  open  source,  Facebook,  Google,  Amazon  and  nearly  every  other  modem 
technology  company  would  not  exist”  (p.  5). 

MOSA  in  DoD 

The  adoption  of  MOSA  within  the  DoD  lags  behind  industry;  this  may  explain  the  lack  of 
program- specific  data  on  the  ROI  for  MOSA  adoption.  Guidance  on  implementing  MOSA 
across  the  DoD  is  pervasive.  The  guidance  can  be  found  everywhere.  The  NDAA  of  2015  directs 
MOSA  implementation  specifically  at  the  program  level  and  the  enterprise  level.  Services  were 
required  to  report  on  their  efforts  to  implement  MOSA.  Repeated  guidance  from  the 
USD(AT&L)  to  implement  MOSA  appears  in  all  three  iterations  of  Better  Buying  Power.  The 
Department  of  Defense  Instruction  5000.2  (DoD,  2017)  directs  program  managers  to  incorporate 
MOSA  efforts  in  their  program  acquisition  strategy.  The  department  has  also  issued  guidance  on 
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how  to  structure  contracts,  with  specific  language  to  support  the  move  to  MOSA  (DoD,  2013). 
Acquisition  guidance  on  MOSA  continues  to  flow  out  and  appears  to  have  a  rising  urgency  and 
mandate  to  use  MOSA  in  acquisition  programs. 

The  Army  COE.  The  Army  Chief  of  Staff  issued  an  execution  order  in  2010  directing 
the  Army  to  begin  development  of  an  Army  COE  to  reduce  the  cost  of  system  development  and 
sustainment,  to  reduce  the  time  required  to  deliver  capability  to  the  force,  and  to  bring  agility  to 
our  ability  to  react  to  the  changing  needs  of  the  warfighter.  The  COE  is  a  set  of  standards  and 
computing  technologies  that  enable  the  rapid  development  of  applications  that  can  be  integrated 
across  multiple  computing  environments.  The  COE  embodies  the  MOSA  construct  and  is  being 
applied  across  handheld,  ground,  air,  mobile  and  command  post  platforms.  The  Army  is 
converging  on  a  common  platform  for  handheld  devices  in  the  mission  command  environment. 
Instead  of  developing  and  maintaining  a  different  mobile  device  for  each  application,  a  single 
device  will  have  the  applications  needed  for  many  functions,  such  as  fires,  medical,  and  language 
translation.  The  same  construct  is  being  applied  to  the  command  post,  where  tens  of  systems  will 
be  converged  on  a  common  software  platform  so  the  soldier  in  the  command  post  can  use  a 
single  system  with  a  common  graphical  user  interface  to  do  multiple  functions  (e.g.,  intel,  fires, 
route  planning).  After  six  years,  progress  is  being  made  on  many  fronts,  and  we  are  reducing  the 
number  of  separate  systems  over  time.  Program  managers  who  provide  systems  for  the  command 
post  have  begun  to  develop  widgets  that  will  ultimately  replace  the  stand-alone  legacy  systems. 
Well  over  50  widgets  have  been  developed.  These  widgets  rely  on  a  common  software  platform, 
and  because  of  the  modular  open  approach,  the  expectation  is  that  many  vendors  can  compete  for 
widget  development  and  innovate  new  solutions.  OSS  makes  up  part  of  the  common  software 
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platform.  As  a  result  the  Army  will  reduce  sustainment  cost  and  the  amount  of  software  it 
maintains  and  speed  up  the  time  required  to  update  or  change  an  existing  capability  or  app. 

Modular  design,  open  architecture,  and  OSS  all  act  to  delay  and  reduce  obsolescence  and 
ultimately  to  reduce  the  cost  of  providing  capability.  According  to  the  Air  Force  Science  and 
Technology  Board  (2001),  in  fiscal  year  1999  the  Air  Force  was  spending  $1  billion  on 
sustaining  aircraft  avionics  and  needed  between  $250  and  $275  million  additional  per  year  to 
address  the  problem  of  aging  avionics  in  new  and  legacy  aircraft.  According  to  Air  Force 
projections,  those  costs  were  expected  to  rise  over  the  next  5  years  by  50  percent.  Combating 
obsolescence  is  a  critical  challenge  for  DoD  systems.  Unchecked  obsolescence  of  DoD  systems 
works  to  increase  the  cost  of  systems  and  decrease  the  systems’  effective  life.  According  to  the 
Air  Force  Science  and  Technology  Board  (2001),  “military  equipment  ages  in  two  basic  ways: 
obsolescence  in  hardware  or  software  that  renders  the  equipment  insupportable;  and  inadequate 
performance  that  renders  the  equipment  unable  to  fulfill  its  mission”  (p.10).  By  developing 
capability  in  loosely  coupled  software  modules  and  using  open  standards,  obsolete  capability  can 
be  easily  updated  with  the  minimum  amount  of  software  to  get  the  job  done  while  keeping  the 
parts  that  still  work.  Integrating  the  modules  with  open  standards  eases  the  integration  of  the  new 
software  and  promotes  competition  among  firms  who  want  to  build  the  updated  software. 

MOSA  applied  across  the  Navy  Enterprise.  The  Navy  has  had  many  successes  with  the 
application  of  MOSA  across  a  number  of  programs.  One  such  effort  is  the  CANES  initiative, 
which  embodies  the  MOSA  construct  and  is  changing  Navy  shipboard  C2.  “CANES  is  a 
shipboard  tactical  network  that  provides  ships  with  services  including  improved  information 
assurance,  firewall  and  intrusion  detection  as  well  as  greater  flexibility  enabling  for  an  adoptable 
IT  platform  to  meet  requirements  for  current  operating  systems  and  easy  upgrades  when  they 
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become  available”  (Pomerleau,  2016,  p.  2).  According  to  Gavin  (2009),  CANES  reduced 
shipboard  networks  to  one  and  is  projected  to  save  $4  million  per  ship  in  a  notional  carrier 
configuration. 

MOSA  and  Intellectual  Property  (IP)/Data  Rights 

As  the  department  seeks  to  accelerate  migration  to  MOSA  where  it  makes  sense,  close 
attention  should  be  paid  to  how  MOSA  will  change  IP  and  data  rights  practices.  As  the  number 
of  vendors  competing  for  contracts  to  update  and  sustain  MOSA-compliant  systems  increases,  an 
increase  in  the  number  of  IP  and  data  rights  problems  is  expected.  The  expectation  is  that  we  will 
see  the  new  MOSA  environment  unleash  competition  and  innovation.  Once  vendors  understand 
the  new  open  environment  and  the  relative  ease  of  developing  software,  the  number  of  software 
apps  being  offered  to  the  government  will  increase.  This  will  add  complexity  to  how  we  develop 
and  manage  contracts.  We  are  likely  to  transition  from  a  few  monolithic  applications  to  a  large 
number  integrated  in  a  common  foundation.  The  developers  of  these  new  apps  will  likely  have  IP 
and  data  rights  issues  that  must  be  addressed. 

Summary 

The  research  uncovered  a  significant  amount  of  data  that  highlights  the  benefits  of  using 
a  MOSA  for  new  and  legacy  systems.  The  Air  Force- sponsored  analysis  shows  a  MOSA 
approach  that  offers  tremendous  benefits  in  reducing  the  sustainment  cost  for  aircraft  and  for 
holding  back  obsolescence  for  these  critical,  long  life-cycle  systems.  Several  Navy  examples 
were  cited  that  show  cost  savings  as  well  as  increased  efficiency  in  reducing  redundant  hardware 
and  software.  The  CANES  initiative  is  already  producing  cost  savings  and  a  positive  ROI.  The 
Navy  also  makes  the  connection  between  MOSA  and  improved  software  reuse.  The  Army  has 
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several  MOSA  initiatives  (VICTORY,  Hardware/Software  convergence,  FACE,  and  COE)  that 
are  expected  to  have  a  substantial  positive  ROI  once  they  reach  maturity. 

Industry  has  fully  leveraged  MOSA  in  many  ways.  Technologies  like  the  service-oriented 
architecture,  cloud  services,  and  the  mobile  device  explosion  are  all  anchored  in  MOSA,  and 
they  have  made  billions  of  dollars  for  commercial  industry.  According  to  the  research  results, 
some  industry  leaders  owe  their  existence  to  MOSA.  Industry  has  outpaced  the  DoD  in  the 
adoption  of  MOSA,  mostly  for  good  reason.  As  we  seek  to  maintain  or  regain  our  technological 
edge  in  defense,  MOSA  will  play  a  significant  part  in  building,  protecting  and  sustaining  our 
systems. 
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Chapter  5  -  Interpretation 


The  collection  and  analysis  of  MOSA-related  data  focused  on  determining  whether  there 
is  a  positive  ROI  for  adopting  MOSA.  Interpretation  and  analysis  of  the  data  showed  numerous 
benefits  of  using  MOSA.  The  benefits  include  reduced  cost  of  development  and  sustainment, 
simplified  integration  of  new  capability,  and  reduced  time  to  develop  or  update  capability.  One  is 
not  likely  to  see  all  these  benefits  on  each  MOSA-related  initiative;  some  will  have  only  one  or 
two.  The  research  strongly  supports  the  potential  of  a  positive  ROI  for  using  MOSA. 

Conclusion 

Based  on  the  research  and  analysis  completed  there  is  and  will  continue  to  be  a  positive 
ROI  for  developing  new,  and  migrating  existing,  programs/systems  to  a  MOSA.  While  it’s  hard 
to  quantify  the  ROI  (savings,  cost  avoidance),  it  is  clear  that  MOSA  is  the  right  strategy  in  many 
cases  and  should  always  be  considered.  Based  on  projected  savings  in  the  area  of  avionics, 
convergence  of  hardware  and  software  to  a  MOSA  construct  is  expected  to  yield  an  ROI  in  the 
hundreds  of  millions  of  dollars.  MOSA  represents  change,  and  change  disrupts  the  current  state. 
We  must  find  a  way  to  address  the  many  sources  of  resistance  to  MOSA.  The  sources  of 
resistance  are  rooted  in  technical  differences,  current  developers’  fear  of  lost  revenue,  and 
resistance  to  change. 

The  research  proves  the  stated  hypothesis  that  “applying  MOSA  to  Army  systems  will 
reduce  the  cost  of  systems  development  and  sustainment.”  However,  the  research  results  did  not 
fully  quantify  the  ROI  for  MOSA  implementation. 

Recommendations 

1.  Resist  broad  MOSA  mandates  on  systems  without  a  business  case  analysis  to  ensure 
the  approach  is  effective  for  the  program  or  system  being  considered.  MOSA  should  not  be 
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applied  as  a  silver  bullet  to  all  programs,  especially  legacy  systems.  There  will  be  instances  when 
applying  MOSA  will  not  make  sense.  Examples  include  when  a  program  is  scheduled  for  end  of 
life  or  when  the  program  architecture  will  not  benefit  from  MOSA  migration. 

2.  Identify  ways  to  incentivize  program  managers  to  implement  MOSA.  Migrating 
systems  to  MOSA  will  likely  constitute  a  significant  change  for  the  program  and  could  drive 
adjustments  to  the  program  baseline  and  interrupt  exiting  contracts  and  contractors.  Because 
program  managers  will  likely  face  pushback  managing  the  change,  giving  them  an  incentive  may 
help  the  process  go  more  smoothly. 

3.  Engage  with  current  systems  maintainers  to  address  their  fear  of  loss  of  income.  As 
mentioned  previously  the  incumbent  contractor  will  likely  resist  the  switch  to  MOSA.  At  best  it 
will  result  in  competition  for  the  contractor.  The  prime  contractor  on  the  program  and  industry 
overall  should  understand  that  they  can  still  thrive  in  a  MOSA  environment.  It’s  up  to  the 
government  to  help  them  see  success  in  a  MOSA  environment. 

4.  Increase  training  on  ways  to  implement  MOSA.  It’s  not  okay  to  assume  that  program 
managers  and  their  staff  understand  how  to  implement  MOSA.  Additional  training  should  be 
made  available  upon  request. 

5.  Fully  embrace  OSS  as  a  component  of  MOSA.  It  has  been  identified  as  a  key 
component  of  modular  open  systems  approaches.  Government  policy  directs  serious 
consideration  of  OSS  before  developing  new  software  products.  Using  OSS  can  reduce 
development  and  sustainment  cost.  A  potential  added  bonus  of  using  OSS  is  it  can  reduce  your 
development  time  by  using  software  that  has  already  been  developed  and  tested. 

6.  Promote  the  FACE  approach  as  a  “best  practice”  for  MOSA,  with  DoD  and  industry 
partnerships.  The  FACE  consortium  includes  industry  and  government  working  to  define  the 
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specifications,  standards,  and  compliance  criterion  for  FACE.  Industry  and  government  jointly 
developing  the  products  and  processes  under  an  agreed  governance  structure  is  an  ideal  approach 
to  building  products  and  trust  that  benefit  all. 

7.  Continue  to  develop  and  refine  metrics  for  MOSA  implementation.  While  the  open 
source  architecture  task  force  and  the  Navy  have  developed  MOSA  compliance  products,  there  is 
still  a  need  for  additional  metrics  to  help  program  managers  assess  their  progress. 

8.  DoD  must  engage  more  in  standards  organizations  and  OSS  forums.  To  ensure  the 
right  standards  are  developed  and  chosen  will  require  engagement  by  DoD  in  the  forums  that  are 
often  led  by  industry.  Likewise,  engaging  in  OSS  forums  give  the  government  a  chance  to  shape 
the  final  product  in  a  way  that  best  serves  the  government. 

9.  Future  research  in  the  area  should  focus  of  automated  tools  to  evaluate  legacy  code  for 
the  existence  of  modular  code  and  openness. 

Limitations  of  the  Study 

As  currently  defined,  MOSA  is  a  broad  term  and  touches  many  aspects  of  systems  and 
software.  Because  of  the  complexity  of  MOSA,  it’s  probable  that  more  program  managers  are 
implementing  some  aspects  of  MOSA  but  are  not  publicizing  their  efforts;  consequently,  this 
research  probably  missed  some  MOSA-related  work  being  done  across  the  DoD.  There  was 
inadequate  data  to  determine  the  cost  of  DoD  participation  in  standards-setting  organizations  and 
open  software  forums.  This  must  be  determined  to  fully  quantify  the  MOSA  ROI.  As  stated 
earlier,  the  research  clearly  supports  the  hypothesis,  but  the  data  collected  and  associated 
analysis  does  not  quantify  the  MOSA  ROI. 
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Glossary  of  Acronyms  and  Terms 


C2 . command  and  control 

CANES . Consolidated  Afloat  Networks  and  Enterprise  Services 

COE . Common  Operating  Environment 

COP . Common  Operational  Picture 

DoD . Department  of  Defense 

FACE . Future  Airborne  Capability  Environment 

IP . intellectual  property 

MAGTAF . Marine  Air  Ground  Task  Force 

MAIS . major  automated  information  system 

MDAP . major  defense  acquisition  program 

MOSA . modular  open  system  approach 

NDAA . National  Defense  Authorization  Act 

OSI . Open  Systems  Interconnect 

OSS  . open  source  software 

ROI . return  on  investment 

SOA . service  oriented  architecture 

TCP/IP . Transmission  Control  Protocol/Intemet  Protocol 

VICTORY . Vehicle  Integration  for  C4ISR  Interoperability 
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